Computer systems, and other electronic systems may have electronic memory. Some of this may be referred to as “main memory”. Main memory may be built from, for example, dynamic random access memory (DRAM) chips. The DRAMs may be organized, for example, onto memory boards or partitioned into dual in line memory modules (DIMMS). Memory may experience errors like transient single bit errors, multi-bit errors, stuck-at single bit errors, and the like, which can negatively impact the systems in which the memory is located.
An operating system or other control system associated with the computer or electronic system may regard the memory as a logical pool of available memory. The operating system may virtualize the available memory so that it can be managed, shared, accessed and so on by various operating system instances (e.g., applications, threads, processes, programs). Thus, physical memory addresses may be translated to virtual memory addresses and vice versa by one or more logics.
Memory usage may vary during system operation depending, for example, on the type, number, size and so on, of applications running on a system. The variance may lead to some memory areas being used frequently while others are used less frequently. If a system is configured to detect memory errors, then errors in more frequently used areas may be more likely to be discovered, accounted for, handled, and so on than errors in less frequently used areas. Thus, errors in less frequently used areas may go undiscovered and may eventually evolve into catastrophic errors as the errors accumulate.
Conventional systems may have employed application level “software memory scrubbing” techniques in an attempt to exercise memory, and to discover, account for, and perhaps correct certain memory errors. However, conventional software memory scrubbing may negatively impact system performance by disturbing (e.g., interrupting, halting, messaging) an operating system, control system, or user level application and/or by consuming non-memory resources (e.g., processor cycles, file table entries, process table entries) that would otherwise be available for operating system instances. Furthermore, conventional software memory scrubbing may not be able to access all or even substantially all of the memory in a system if some memory is locked by an operating system, control system, operating system instance, or the like. Additionally, some memory may not be accessible if memory has been partitioned by, for example, an operating system. Thus, errors may still go undetected and may accumulate in areas that software memory scrubbing does not reach. Even if a conventional software scrubber detects a memory area that may have suspect qualities (e.g., parity error detected in location), the application may be limited in its response to the detected error. For example, a software memory scrubbing application may log an error location. The log may then be read by a separate diagnostic software application after a system shutdown and reboot.